IBIS Macromodel Task Group Meeting date: 18 June 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan Stephen Slater Maziar Farahmand Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Fangyi to prepare a version of the DC_Offset BIRD utilizing approach #2. - Done. - Fangyi to send his DC_Offset BIRD presentation to ATM. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the June 11 meeting. Bob moved to approve the minutes. Randy seconded the motion. There were no objections. ------------- New Discussion: BIRD197.3_draft_5(DC_Offset): Arpad reviewed his most recent summary email and highlighted the differences between approach 1 and approach 2 as defined in Fangyi's presentation and discussed at the previous meeting. Arpad noted that approach 1 might also need DC_Offset to be InOut in order to be equivalent to approach 2. Walter noted that he preferred approach 0, simply leaving things alone and sticking with the BIRD197.2 he had submitted to the Open Forum. Ambrish agreed and said he thought the threshold (returned via NRZ_Threshold in approach 2) was what the model needed for itself for error correction and DFE. It didn't need to be returned by the model. He also noted that it shouldn't be confused with the DC_Offset the BIRD originally introduced. Arpad noted that BIRD197.2 did not contain the DC_for_Statistical parameter. He asked if Walter did not want that either. Walter confirmed that he did not think DC_for_Statistical was necessary. Walter suggested returning to BIRD197.2 and possibly drafting a second BIRD for NRZ_Threshold. Walter reviewed a preliminary draft he had written for an NRZ_Threshold BIRD. After the group reviewed it, Fangyi noted that his latest (draft_5) proposal defined NRZ_Threshold in the same way. Walter agreed and noted that he was okay with having NRZ_Threshold and DC_Offset in the same BIRD. Fangyi said he thought we still needed DC_for_Statistical. Walter said it was not needed, and that NRZ_Threshold could be returned by Init() and GetWave(). Fangyi proposed an example in which the waveform at the slicer had a .7V DC offset, but the model had decided the threshold was at .8V. In this case GetWave() could return a waveform containing the .7V offset and an NRZ_Threshold value of .8V, but statistical flow would not be able to provide the .7V offset information. So, the model would produce different results for statistical and time domain flows. Walter said he didn't think it was meaningful for people to ask for the "physical waveform" at the slicer, or to care about the .7V offset relative to some local reference, as this waveform couldn't be readily measured in a lab. Walter suggested the natural thing to do is just worry about the difference between the signal voltage and the threshold voltage. So, the model should simply return the .1V difference between the .8V threshold and the .7V DC offset in this example. Fangyi asked Arpad if he was okay giving up on the offset information and the ability to provide the waveform in absolute terms. Arpad said he was fine with removing the DC_for_Statistical parameter for now, because we could always write a new BIRD later if we discovered that it would be useful to have this parameter. Walter suggested we take Fangyi's latest draft_5, remove the DC_for_Statistical parameter, and add Rx_Receiver_Sensitivity information to the NRZ_Threshold description. Fangyi took the AR to make those updates to draft_5 so that ATM can review it at the next meeting. Complex C_comp modeling: Randy reviewed his latest draft: - Removed use of the undefined term "token" per Bob's suggestion. - Replaced "Mode" Subparam with "C_comp_model_mode" per Bob's suggestion. - Based on a suggestion from Arpad, the text explaining what to do for any undefined modes was moved into its own paragraph. Bob noted one suggestion he had forgotten to make previously. In the "Rules of Precedence" section, Bob objected to the use of the phrase "... assume that [C Comp Model] is more accurate than C_comp*." He suggested "more detailed" to avoid any value judgement on accuracy. Randy was unsure about this suggestion because the whole point of the section is to give a justification for the rules of precedence, and "more accurate" would justify the higher precedence for a [C Comp Model]. Arpad suggested the term "realistic" instead. Arpad expressed concern about the weakness of the final sentence in the section. "The EDA tool may use the [C Comp Corner] values for V-T curve shaping during simulation." He said this statement should be strengthened to make sure model makers understand that [C Comp Corner] is what will be used by tools for deriving the K(t) curves, so the [C Comp Corner] values are critical even when [C Comp Model] exists. Walter agreed and noted that he had experimented with developing an algorithm that would use the [C Comp Model] and an iterative approach to deriving the K(t) curves. He said it turned out to be a difficult problem, so it's important that the model provide accurate [C Comp Corner] values for tools to use during K(t) generation. Walter proposed: "The model maker should anticipate that EDA tools will use [C Comp Corner] values to derive the K(t) curves." Arpad noted that we can continue the discussion next time. - Walter: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Fangyi to modify BIRD197.3_draft_5 to create draft_6 per today's discussion. ------------- Next meeting: 25 June 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives